The invention relates to database software, and particularly to databases residing on mainframe computers.
Large, mission-critical databases such as those used in the financial services industry still reside primarily on mainframes (e.g., the IBM.RTM. 3090 running applications written for IBM CICS/NVS software). Efforts have been underway for several years to move these databases to client/server architectures, in which fault-tolerant enterprise servers (e.g., Oracle.RTM. database software running on a Pyramid server) communicate over local area networks with clients (e.g., Pentium.RTM. class PCs) running graphical user interfaces (GUIs). Conventional wisdom has been that moving databases to client/server architectures will reduce costs, as enterprise server hardware tends to be less costly than mainframe hardware. The other major motivation for moving to enterprise servers has been to provide users with GUI clients, which are a more user-friendly interface than the IBM 3270 terminal interface typically used with mainframes.
Not uncommon today is a three-tier architecture, in which a GUI client communicates with an enterprise server, which, in turn, communicates with a mainframe. Typically, the mainframe is running legacy software (e.g., written in COBOL) that handles the core data of the application. Additional data and editing of mainframe data are handled by the enterprise server. Data is downloaded from the mainframe (e.g., in nightly batches) to the enterprise server, and from there made available to the user via the GUI client.
Although mainframes are still dominant, changes have occurred at the user's desktop. At the time that today's mainframe software was written, users typically ran only mainframe applications, and did all of their computing via terminals, the most common of which was the IBM 3270. But as desktop computing became commonplace (e.g., with the appearance of desktop word processing and spreadsheet software), the terminal was largely replaced with terminal emulation software (or hardware/software hybrids) running on the user's desktop computer. But such terminal emulation produced the very same character-based interface provided by the original terminal.
Each screen map appearing on a mainframe terminal or terminal emulation is produced by the mainframe software. For example, data is exported to the terminal via a SEND MAP instruction written in COBOL, and data is received via a RECEIVE MAP instruction. At that point in the program execution, a logical map containing the data fields is mapped into a physical or character map that contains the data plus a variety of screen attribute commands (e.g., color, underlining). Only the character maps are sent to the terminal.
Efforts have been made towards replacing this character-based terminal interface with a GUI. Much of the investment in conversions to client/server architecture has been driven by the desire to provide the user with a GUI.
Screen scraper software has been used to create GUIs from the character maps sent to the terminals, but without a great deal of success. Using a screen scraper to do the conversion depends on absolute accuracy of transmission of the character maps. A single character lost in transmission (as can happen particularly with software emulations, which lack the error checking of the original terminal) can result in a lockup (i.e., a complete failure requiring re-starting) of the screen scraper software or in all of the data on the GUI being erroneous. The same outcomes can result from making a minor change to the mainframe software, as a change may slightly shift the location of data fields in the character maps.
GUIs produced using screen scraping are also typically limited to presenting information appearing on a single character map received from the mainframe. Adding additional data fields not stored on the mainframe, or combining data appearing on different character maps, has required moving the database to a client/server architecture.